feat(cloudflare): map service tokens to user subjects - #1610

Summary

• let operators map a Cloudflare service-token common_name to a human Access sub
• keep service tokens on the member role, without copied email, admin, or group claims
• reject malformed, duplicate, and identity-less claims
• document setup and bearer-token implications

Context

Cloudflare service-token JWTs contain a client common_name, but no human sub or email. That makes a headless MCP client a separate Executor account, so it cannot use the human's personal connections.

ACCESS_SERVICE_TOKEN_SUBJECTS adds an explicit mapping at the Access identity boundary. It changes only the account ID used for user-owned data. Mapped and unmapped service tokens remain members and never inherit the mapped user's email, admin role, or groups.

Verification

• bun run format:check
• bun run lint
• bun run typecheck
• cd apps/host-cloudflare && bun run test (29 tests)

The full repository test run found two unrelated parallel-run flakes in stdio-integration.test.ts and one OpenAPI form-body test. Each failing test passed in isolation.